NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/lang/c++-part2/16389

Internet Message Format | 1996-08-05 | 6.2 KB

Path: keats.ugrad.cs.ubc.ca!not-for-mail
From: [e-mail] (Kazimir Kylheku)
Newsgroups: comp.lang.ada,comp.lang.c,comp.lang.c++,comp.edu
Subject: Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)
Date: 10 Apr 1996 09:12:41 -0700
Organization: Computer Science, University of B.C., Vancouver, B.C., Canada
Message-ID: <[e-mail]>
References: <[e-mail]> <dewar.829079393@schonberg> <[e-mail]> <dewar.829135457@schonberg>
NNTP-Posting-Host: keats.ugrad.cs.ubc.ca

In article <dewar.829135457@schonberg>, Robert Dewar <[e-mail]> wrote:
>Kazimir says
>
>"Dewar: in the absence of clarity in a standard, as an implementor, follow the
>pack. Look at what most implementations do, and stick to the unwritten
>standards of the community."
>
>That of course completely misunderstands my position and Kazimir's failure
>to undertand the central issue here is a great illustration of my central
>point. In fact I could not have asked for anyone to make the point
>more clearly.
>
>I brought up this thread not as a discussion of proper programming
>practices, but of the importance of specs, and to give an example
>of portability problems caused by inaccurate specs.
>
>Kazimir's view is "so what if the specs are vague, never mind, if people
>are "rational" or follow "unwritten rules", then it probably won't matter
>much.
>
>The trouble is that it absolutely *does* matter, and it matters much!
>If programmers continue to follow Kazimir's casual attitude towards
>specs, then we continue to get libraries, and, as we see in the case
>of POSIX, even standards, that are unacceptably vague.

You are quoting me unfairly and out of context, as anyone who follows back to
the article your are replying to can plainly see. At the bottom I say:

%As a programmer, if you do the former [try to do your best to live with
%imprecise specs---you have work to do after all!], you don't have to
%particularly worry whether an implementation does the latter.  For example,
%because I don't assume that select() will not modify the timeval structure, I
%don't have to care whether it does or not.
%
%The trouble is that the combined effect of the two motivations results in
%nothing being done to fix the standards. Good programmers are careful anyway,
%so they don't care, and those who are not careful are forgiven by most of the
%implementations, so they don't care (or don't even know) either.

This clearly shows that I also think that it *does* matter. The standards don't
get fix because programmers get used to working around the flaws, and
implementors follow unwritten rules (which you advocate: you are the one who
said that Linux should so things like the other UNIXes to alleviate portability
problems).

>I am not asking for formal specifications, although with library
>routines like this it would not be too hard, and would definitely
>be useful, but I think people need to have more formal training
>in semantics, so that they understand the critical issue of
>clear specifications.

I however am asking for formal specifications.

>The bravado attitude of Kazimir and Peter -- "people shouldn't make
>errors, if they do they get what they deserve", or "people should
>think clearly, real programmers don't need specs [to be fair that
>is Kazimir and not Peter]" is actually often more of a menace
>than incompetence. I have often seen big programs get into horrible

That is completely false. I never said any such thing. I advocated a certain
course of rational action in the absence of clarity in the spec. I did not
state that one should get what one deserves, or that the specs are not needed.
Clearly, how can anyone advocate the that viewpoint ``real programmers'' do not
need specs? All I did was state that when you have specs that are not perfectly
comprehensive and can you are aware that they can be interpreted in more than
one way, pick the safer alternative if you can. If you are not aware, I don't
claim that you are a bad programmer. In fact I pointed out how I was bitten
myself by the differences in select() semantics, and that I sympathize with
your viewpoint due to my first-hand experience.

>trouble because a really clever programmer thought that rigorous
>engineering could be replaced by programming brilliance.
>
>As I have said many times, the details of the read issue are not that
>important. It is simply a case where different implementatoins have
>subtly different specs, and consquently a program that is semantically
>correct in one implmentation is wrong in another. The only cure to this
>problem is clear specification at an abstract, implementation-independent
>level. People who think that they can overcome the lack of such clear

Yes, that is the cure. But the individual programmer doesn't have access to
such a powerful remedy. Standards take time to evolve and crystallize. I may
_want_ read() to work a certain way but the task of convincing the whole world
to move over to my precise conception is not easy!

Not every programmer can afford to get outraged and calls ANSI, IEEE or ISO to
call a new committee together to fix something and than wait until it's done!
I'm a little upset about POSIX, but so be it (for now). This is something that
I don't control.  Maybe one day I will sit on a standardization committee and
will make sure that nothing falls through the cracks, but right now I'm just a
standards _user_, for better or worse.

>abstract specifications by guessing what is rational or reasonable
>are fooling themselves badly.

Or maybe they are just getting work done the best they can with what is
available, like I'm sure you are!

The GNAT runtime calls read() happily. It messed-up under Linux, and was fixed.
The problem was brought to prominent attention, which kick-started the
reasoning process that led to a more prudent interpretation of standard and an
implementation that works under Linux _and_ the previous ports. This is what
anyone would have done under the circumstances. I never claimed that this would
have never happened to a ``real programmer'', and don't wish to be interpreted
in the worst possible way if there is misunderstanding.

In the absence of clarity in any of my postings, please assume the least
harmful or arrogant interpretation. :)
--